|
|
| Author |
Thread Statistics | Show CCP posts - 44 post(s) |
|
CCP MC Peanut
Science and Trade Institute
Caldari State
1
   |
Posted - 2014.05.10 08:59:00 -
[1] - Quote
Hey Everybody, CCP MC Peanut here--new to the forums (and this is my first post). I'm a Technical Artist here in Shanghai and was mostly involved in the HUD upgrade for the Project Legion Prototype you saw at Fanfest. I'm excited you guys noticed the work and are discussing it. The feedback is super awesome too (so awesome I forwarded the post to a lot of other devs). I thought I would jump in and give a little further explanation about what we did and potentially where we can go from here.
The HUD that you see in the Project Legion Prototype showed at Fanfest is now being rendered inside the 3D Scene. This is a significant change. While what you saw in the demo isn't incredibly different to what was there before, I want to emphasize that we have completely changed the underlying system for creating HUDs and have built a pipeline that puts the artist and designers much closer to the implementation. What you saw was the first implementation with the new system. And while the demo doesn't demonstrate it all--everything is working. In a very short time (a few weeks maybe), a few of us rebuilt the HUD, recreated all the logic, and tuned it to a slightly new visual design.
I'd love to go a little more in depth and explain some of the cooler benefits we are finding with this change:
Artist and Designers can iterate like crazy:
Unreal already has a lot of robust tools available to it, so why not take advantage of them. One of the things the artist love the most is being able to play the game with the editor open and update their material parameters in real-time. The 3D HUD is heavily utilizing the Unreal Material system. For example, all the 'bars' stem from the same base material, which has parameters to control the scale of the ticks, space between, color (including switching the color over position), flashing (speed and color). Tuning these parameters in-game is pretty awesome and very easy. Another example, the most obvious one probably, is that since it is 3D, we can change the position and layout very easily--it is as simple as moving it in the 3D package (Maya) and re-importing the geometry.
Logic outside of code
This was an interesting choice, but I believe it was the right one. We are exposing game data to the artist/designer through events in the visual scripting system, called Kismet (if you aren't familiar with Kismet, it is a node based scripting tool provided within Unreal that allows artists and designers to do more 'programmatic' things). With this change, much of the logic is in the hands of the content creators--the programmers are only responsible for providing the information when applicable. This sounds like it could become overwhelming, and we have been careful about not suddenly dumping everything in their laps. I can give one example. When your shield value changes, an event will be fired (a kismet event inside the HUD map file). This event will expose the current and max shield value. Luckily, our bar material has a max and current parameter input, so we just update the values (using a Kismet action) and all is good. While this is something that sounds like it could be completely programmatic, it is so much nicer to give the content creators the flexibility. If we wanted to, we could trigger a distortion animation every time the armor value changed, and as the armor got lower, the distortion could be more significant. This would require zero programmer support.
Lots of technology to utilize
Because we are in 3D we have access to all the rendering technology as other 3D stuff (suits, weapons, environments). We can also utilize the same tools (materials, modeling, an animation) that our 3D artists are familiar with, so the transition for workflow, was not so bad.
Capacity to be Dynamic
I can't make any promises about racial HUDs, but we are definitely in a much better position to be able to do them. It is very easy to create new 'visual' components without needing to rework the data hookup--and they would be lightweight and low cost.
There is more, and I could go on, but perhaps that is better for follow up posts. Our hope is that we have built a system the is flexible enough to give us more options to do the kinds of things you guys are asking for. Regarding these requests, I can definitely weigh in on their possibility within the system, but I am unable to comment on the likelihood (that is someone else's call). Please keep the feedback coming, and feel free to post follow up questions.
thanks! |
|
|
CCP MC Peanut
Science and Trade Institute
Caldari State
44
|
Posted - 2014.05.11 09:45:00 -
[2] - Quote
Ryder Azorria wrote:
First things first, great dev name.
Second, thanks for basically writing out a dev blogs worth of cool info.
Thanks, and thank you for the great welcome (to everyone)
Vaux Karn wrote:Customizable opacity for individual HUD objects. I say individual HUD objects because I want to be able to tune certain things to make them less obstructive without making thins like the radar harder to see.
This is a cool idea and is likely possible. One way we could set this up is have root materials for each component and make sure that every element on said component inherits from this root. Then we set the opacity value on the root material and all the children update. The only issue is that some materials already have parents. Armor and Ammo share the same parent material that deals with 'all things bars'. We could work around this by creating an intermediate root (hierarchy depth isn't expensive) of like "WeaponBars" and "SuitBars". That could be managable--it isn't what we have setup currently, but it also wouldn't be a big deal to make that change. There may be another way to do this by using the mesh information (since components would be on a related mesh): we may be able to pack some information (opacity scale) into the mesh actor that can be exposed to the shader (and be used as a scaler on opacity). To me, that would be a bit cleaner, but I'd have to check on with an engineer on packing that data.
Vrain Matari wrote:In terms of system resources, how does your implementation compare with what we currently have in DUST?
We haven't done thorough testing on cpu performance, but rendering performance is pretty good because we are using the same rendering technology as the game; also our shader use is really efficiently (3 base shaders so far). In terms of texture memory, we achieved a great reduction. The previous HUD used a massive texture atlas. Each HUD element requires unique pixel information. The new 3D HUD, since it uses polygons and shaders, doesn't. For example, in the bars, the curvature is done on the polygons and the texture is tiled across them, so we ended up needing about 64 x 64 total pixels of texture memory to display all variety of bars. The previous HUD wasn't able to do this and required a LOT more texture memory. Also the previous HUD couldn't benefit from shaders, so some elements had color variations duplicated in the textures.
Robert JD Niewiadomski wrote:
This is cool and seems very relevent--I can pass it on to the designers. We like to look at how other people do things.
A fair amount of responses related to Racial Huds, Customization, and the Minimap, so I'll try to address those here:
Minimap Improvement
I may have been a little unclear in my first post when I proudly said we moved everything to 3D. Definitely everything in the hud is rendered on a polygon, but some of the textures are still going through the old system, output to a renderTarget texture and mapped to a material on said polygon. The minimap is one of these elements that is coming form the renderTarget (also the text). This is actually very common practice for 3D Huds/UIs, but it is not as scalable or dynamic as going full 3D. We can still utilize Unreal Materials, but it isn't as robust. For example, I can adjust the color of the minimap, but I can't easily adjust the color of only the enemy icons (without changing the renderTarget or touching source textures). The minimap looks visually different because a UI Designer updated the source textures, but the behavior is still technically the same. We actually knew ahead that the Minimap was going to be complicated so, given the time constraint, we made the decision to use it as a renderTarget with the hopes of coming up with a robust system later. Likely what we are looking at is some way of representing 3D Icon/Marker positons, with the position proided by the game (converted into a local space coordinate).
The things we will need to watch out for are:
* positional updates happen frequently and may be costly to performance
* many elements (markers) to position may be costly if they are all unique actors
The benefits we will get:
* easy to tune visual look of individual elements (markers)
* easy to adjust the position or orientation, or coordinate space the icons fall in
* can attach events or states to markers and do things (like flash, glow, scale)
Racial Huds
Super cool how much you guys have thought about this and the designs are absolutely amazing. Technically speaking, the workflow for doing racial HUDs is no different than the workflow for creating the Fanfest HUD, but repeat for each race. The old HUD system was less scalable and not incredibly dynamic, so doing this would have been a fair undertaking. The new HUD system is much more scalable, efficient, and implements easier, so we probably aren't looking at nearly the same cost.
There are still some elements (Minimap for example) in the new HUD that are just 'old hud system mapped as a texture'--these would either need to be fully recreated in 3D, or we would be forced to create their racial variants in the old system and map them to a texture. Since there are only a limited number of races, having to do some of the racial variants in the hybrid way doesn't immediately rule it out, but it would require us to carefully look at the costs and make sure we don't exceed limitations. That being said, we don't want to have to compromise and be held back by un-scalable things, and are currently having truckloads of coffee and other brainstorming-favorable snacks imported into the country.
Customization
Customization is definitely easier with a 3D dynamic system. The HUD polygons meshes are already broken into groups and can be moved independently. So technically, yes this is very possible, but there are some considerations to be aware of:
* Each group has it's own pivot point for movement (and not all are the same), if we move these around, we would need to make sure the pivot point is adjust correctly too
* If we add 3d Animations (not the movement stuff) for the HUD (we haven't yet and it is undecided yet if we will) t... |
|
|
CCP MC Peanut
Science and Trade Institute
Caldari State
50
|
Posted - 2014.05.11 12:13:00 -
[3] - Quote
Monkey MAC wrote:
You could use an abstract method to set up all bars the same, then wrap dynamically created classes.
I.e Class name: Armour Bar (contains instances of Armour Bar Segement)
This way with a little clever logic you can
1) Standardise a behaviour method for all bars, so they all react in the same way
2) Overload the behaviour method, so there is only 1 method call with multiple effects
3) Inherit these methods for over writing.
.
Actually you pretty much hit the nail on the head with what we were doing with the Bar setup and other HUD functionality (although it is pretty Bar-stuff heavy). Rather than creating actor classes, though, we've put everything in a hierarchical material setup. It is 'fairly' object oriented, in that I can define parameters (barValue, barScale, barColor) on the parent material that can be overridden on the child materials. It is by no means as robust as driving this with classes, though--so your suggestion still makes me consider the alternative. Another benefit to keeping things in materials is that we can do upgrades and changes on the content side. I can edit the shader to have distortion, expose the parameter, and set it (on the root material) in kismet. Pretty nifty.
I do think if we try to implement a standardized 3d icon system, that this is the way to go (as we will have more complexity with states and such) |
|
|
CCP MC Peanut
C C P
C C P Alliance
86
|
Posted - 2014.05.12 11:27:00 -
[4] - Quote
IgniteableAura wrote:MC Peanut,
Is it possible to make the health bars more dynamic based on shields vs armor? So that when you are shooting someone you have an idea where their "tank" is?
So for example the armor bar would be red and the shield bar would be blue. Each would be proportional to their total HP.
I might not be understanding your question correctly, so feel free to bark back if I answer it wrong. Health and Armor bars could have a bar 'tick' (or do we call these cells?) for each unit of armor/health. This is the basic setup on our material: there is a 'barScale' parameter that will tile/repeat the bar texture (which is always a texture of 1 cell/unit/tick) by whatever the numeric value is. But in the case of Health and Armor, we have pretty large values, so repeating the ticks so much ends up kind of ugly, so we need to set the barStep parameter, which represents the number of numeric units that each texture 'tile' stands for. So if I set the barStep to 2, and the scale is 10, I see 5 cells (when full). Currently on the suits we are dividing their maxAmmo value by a constant scalar value so that they end up having the same number of texture repeats, but we don't have to. In the ammo department we are actually representing them more accurately, but once the ammo count gets high, we start setting the barStep.
Part of me thinks you are asking the health bars of the person you are shooting, though? This could happen--it would have to be part of the targeting info, or the data would at least have to be provided by the same system that grabs the target info data, but we could put it somewhere else.
And the bar colors can be whatever we want--that is just up to the designers.
Robert JD Niewiadomski wrote:
You guys commented so much about the compass being cool that you've inspired me to make it functional. There are a few ways to go about this. I think the best choice for me is to do it on the shader and apply a texture coordinate offset. Hopefully this works across all maps (sometimes sockets are rotated, but I don't think this would cause a problem)
And the other elements--I can't comment on their purpose at this moment, but I can say that they are functional.
Cat Merc wrote:Question: Since this new method is memory efficient, would this work on DUST and the PS3?
Considering it has 256mb of VRAM, I would assume every little bit counts, and could somewhat improve performance.
Well once we drop the requirement of the renderTarget our HUD texture memory usage will definitely lower than on ps3, but currently we still have some 'hybrid' elements that require a decent sized renderTarget. Best case is down the road we fully 3D-ify and don't need a renderTarget for the HUD at all, worst case is we still need some of it, which means we would need to take our current renderTarget and optimize the memory footprint it uses.
Another concern would be that the 3D HUD was built alongside some graphics tech updates to our Engine, and it may have certain dependencies on them. It is doubtful these updates could go back to the PS3, so if there is a dependency we may have some adjustments to make.
Outside of that, it should be able to work on PS3. |
|
|
CCP MC Peanut
C C P
C C P Alliance
87
|
Posted - 2014.05.12 12:02:00 -
[5] - Quote
Monkey MAC wrote:
Yeah that is what he means, especially now a days in DUST brick tanking is all the rage. You will see caldari's with more armour than my Minmatar has EHP. It would be useful knowing if this is the case, so I can make a more informed descision about the engagement.
Personally I would achieve this by merging Shields and Armour into a single bar for enemies. Light Red for Shields and Dark Red for Armour, so if a gallanteans EHP consists of 20% Shields and 80% it will look something like this.
S S A A A A A A A A
Ah cool I got it (good explanation!). Also we could likely take the max amount and use them as scalars to drive some other value that helps give some visual indicators to their max without spelling it out (although it could be spelled out if we want, but that's for design). We could play with the unit spacing, intensity, or color.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
119
|
Posted - 2014.05.13 12:37:00 -
[6] - Quote
The feedback continues to be great.. As awesome as you guys find Dev responses, the feedback you are posting is super stellar (space themed games deserve space themed adjectives).
The shield-armor ideas for the targeting info are absolutely possible. And I much better see your point on the benefit of being able to discern the ratio between Armor and Shield. What do you think is the best way to show the current value of the Armor Shield, but still preserve the ratio relationship? I'm thinking you could either use 4 colors (2 for depleted, 2 for not), or a secondary bar or two underneath--could be thin. Also we could still do it with 2 colors, but layer 2 bars over each other and have the bottom one not update.
COMPASS WORKS
I was inspired by you guys. I know we would have done it sooner or later, but after hearing so many people woot the presence of the compass and not seem to upset that it was non functional, I had to. And it wasn't very hard. I ended up doing it in the shader. I was able to figure out the world space camera vector and then used a custom material node (which is just a place to write hlsl) to convert the vector to an angle range. Then divided this by pi left me with a -1 to 1 value, which I used to drive the U coordinate position of the texture. Also I exposed an offset value so I could go into a map, orient myself north, and plug in numbers to the offset until the compass was correct. Now back to the artist to create a texture for the full 360 view.
Hopefully we can show this off very soon in an actual Dev Blog post.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
120
|
Posted - 2014.05.13 12:42:00 -
[7] - Quote
Maken Tosch wrote:@CCP MC Peanut
Since you're here, I like to point out something that has gotten me a disoriented (literally) when I was playing Dust.
Every time I spawn in at any location whether it's an uplink, objective, default spawn, or CRU, I get completely disoriented upon spawning in to the point that even with the help of the compass I am momentarily unable to get a sense of direction. I'm serious. For some reason my sense of direction goes the way of the dodo bird during that first moment immediately after spawning. Of course, a moment or two later I regain my sense of direction thanks to the compass and then all is right again.
I don't know if this has anything to do with just biology and maybe this is just me experiencing this and no one else.
In any case, this seems like something that can best be addressed with a subtle visual cue built into the spawn points when I'm in the map overview screen. If an uplink is facing a specific direction, I like to know before I pick that spawn. I don't want to spawn in facing a wall while a redberry has his gun to my back. But the issue with the disorientation comes in when spawning in via the objectives and CRUs where I can spawn in at a random point at a random direction. Am I going to spawn in facing the objective or away from the objective? Am I going to spawn behind that barrier or out in the open?
I'm not sure if they purposely orient the player when spawning or not. My guess is they do, but I can't say for sure. Either way they can orient the player and likewise indicate this somehow on the overview map. If we end up moving the icons on the overview map to the 3D system, I'll keep this in mind.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
139
|
Posted - 2014.05.14 01:14:00 -
[8] - Quote
Monkey MAC wrote:
I think instead of these kind of things being customizable, we just have them react to the enviroment.
So say your on a Thermonically Active Planet, there is soot and particulates everywhere, your DOF is limited to say 20m, your suits systems reacts and you get a pulsed grid overlay, that outlines buildings/terrain and enemies that would normally be in your FOV .
Say your on a Desolate Jilted Planet, so there is no star close enough to provide light, you are in pitch black, your suit systems react by giving you a IR night vision, however this can be as much a blessing as it is a curse since, flare effects such as Mass Drivers, Muzzel Flashes, Turret fire can potentially blind you.
Say you are on a Close Proximity Exo-planet, the sun is so bright it will burn your eyes, your suit reacts by turning down the brightness on your helmet feed, however walking in and out of buildings require time for the brigtness to readjust
Then add a few little touches to make it more immersive
Ice on the edges of your visor
Overly defined pixels after a flux, or blinding grenade
Cracks during armour damage
Having the HUD physically load in the first time you spawn
Having the HUD react to clone failure (some flashing red text center screen)
that kinda thing.
Excellent points and outstanding dialogue. Again, the decision on doing this is not mine to make, but the artist in me would find these very fun to figure out and work on. Of course, that in itself isn't reason enough to do them. Designers would have to carefully consider the balance and affects to a player's gameplay.
But possibly speaking, absolutely. I can think of a couple ways to accomplish these 'view modes'. One would be to replace all objects in the scene with another material type--xray, infra, ultra, etc. But a shader alone could be complicated to be accurate. For example, infravision should show heat, but we don't track this information on a per pixel level. We *could* create a different texture map to represent the surface heat of objects, but that seems like it could be expensive. Also we *could* tag vertex colors with a value to represent this, but this would be a fair workload to go back and tag everything. There may be an easier, but less accurate way, which would be to just guess based on some material information, such as the specular power (tells you how much light is bounced off rather than absorbed), emissive value, and the light intensity affecting it. This would probably get you something pretty accurate for things that don't generate their own heat and only absorb from the environment. But yea, having diagnosed this I'd say it could turn into a fair amount of work, and that was just infra-vision.
Cracks and pixels overlay could happen, and we can be flexible how they happen. If we want we could put a 'visor' model in the scene and put the cracks on it, so we can control the depth that the happen at. Maybe some HUD elements are holographic projections and others are part of a screen--this would give us that control. Also we can separate the effect based on armor or shield damage. The challenge will be balancing the variation in effects and dealing with overlapping effects. I imagine there will be some limitation that requires us to group effects and only be able to display one from each group at a time.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
153
|
Posted - 2014.05.14 11:40:00 -
[9] - Quote
Bragoltur Valaruina wrote:Hey CCP MC Peanut, I have a few questions about vehicles, and especially dropships.
Is there a possibility of,
A. Getting a pitch/roll meter when in a dropship?
B. Dropships in general but especially assault dropships need to point at a much lower angle when *scooped*. The current zoom feature does very little good, sense you are forced to pitch down to shoot anything low than you in that view mode, and because pitching forward causes you to move forward, you get a pretty small window of opportunity.
D. A speedometer across the board for vehicles would be really nice.
A. Getting a pitch/roll meter when in a dropship?
Absolutely possible. To do this we would expose the pitch and roll values to kismet. There are a few ways to represent this visually, and probably it make less sense to use the bar material, but we could have some sort of gauge with a dial or us a rolley ball thingy (I'm sure there is a more scientific name). This probably means we would need to represent it with a 3D Skeletal Mesh and dynamically position it based on numerical inputs. Driving Mesh animations with dynamic values (as opposed to material) is not something we've fully scoped out yet, but I think we could do it using animation trees and blending between end point 'poses'. In the case of a dial the poses would be a single keyframe animation for the max and the min values (and the blend an 0 to 1 value that finds the exact value).
B. Dropship pointing
I don't have a lot of familiarity with the inner workings of vehicles. Maybe another dev can jump in? But I'd wager this is something that is tune-able.
C. What. no C?
D. Speedometer
We could do a dial or digital speedometer (or a bar). This would require getting a speed value change in kismet. This would be something that may have a performance issue because velocity could change very often. If it was a problem we could set the events to minimum delay time between successive fires (this is built into Unreal), but we would have to make sure it is not jerky--probably not, but it may be something that forces our hand to choose a Digital display over a Dial.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
160
|
Posted - 2014.05.14 11:59:00 -
[10] - Quote
Monkey MAC wrote:CCP MC Peanut wrote:Monkey MAC wrote:
I think instead of these kind of things being customizable, we just have them react to the enviroment.
So say your on a Thermonically Active Planet, there is soot and particulates everywhere, your DOF is limited to say 20m, your suits systems reacts and you get a pulsed grid overlay, that outlines buildings/terrain and enemies that would normally be in your FOV .
Say your on a Desolate Jilted Planet, so there is no star close enough to provide light, you are in pitch black, your suit systems react by giving you a IR night vision, however this can be as much a blessing as it is a curse since, flare effects such as Mass Drivers, Muzzel Flashes, Turret fire can potentially blind you.
Say you are on a Close Proximity Exo-planet, the sun is so bright it will burn your eyes, your suit reacts by turning down the brightness on your helmet feed, however walking in and out of buildings require time for the brigtness to readjust
Then add a few little touches to make it more immersive
Ice on the edges of your visor
Overly defined pixels after a flux, or blinding grenade
Cracks during armour damage
Having the HUD physically load in the first time you spawn
Having the HUD react to clone failure (some flashing red text center screen)
that kinda thing.
Excellent points and outstanding dialogue. Again, the decision on doing this is not mine to make, but the artist in me would find these very fun to figure out and work on. Of course, that in itself isn't reason enough to do them. Designers would have to carefully consider the balance and affects to a player's gameplay. But possibly speaking, absolutely. I can think of a couple ways to accomplish these 'view modes'. One would be to replace all objects in the scene with another material type--xray, infra, ultra, etc. But a shader alone could be complicated to be accurate. For example, infravision should show heat, but we don't track this information on a per pixel level. We *could* create a different texture map to represent the surface heat of objects, but that seems like it could be expensive. Also we *could* tag vertex colors with a value to represent this, but this would be a fair workload to go back and tag everything. There may be an easier, but less accurate way, which would be to just guess based on some material information, such as the specular power (tells you how much light is bounced off rather than absorbed), emissive value, and the light intensity affecting it. This would probably get you something pretty accurate for things that don't generate their own heat and only absorb from the environment. But yea, having diagnosed this I'd say it could turn into a fair amount of work, and that was just infra-vision. Cracks and pixels overlay could happen, and we can be flexible how they happen. If we want we could put a 'visor' model in the scene and put the cracks on it, so we can control the depth that the happen at. Maybe some HUD elements are holographic projections and others are part of a screen--this would give us that control. Also we can separate the effect based on armor or shield damage. The challenge will be balancing the variation in effects and dealing with overlapping effects. I imagine there will be some limitation that requires us to group effects and only be able to display one from each group at a time. Would it be possible to cheat? Instead of being absolute black, make it dark enough the human eye can't discern shapes or colours, then invert the brightness like a negative image, then make interactable objects, like infantry, vehicles and equipment emit/fluoresce a darkness/black light, even to a lesser degree instalations could do the same. Im not sure how well this would work, but it be alot simpler than adding in whole new , material textures.
It is definitely something we would spend some time playtime with/prototyping. And creating new materials isn't a terribly big deal. Replacing all objects in a scene with new materials could be. Also we have a way to assign these materials ahead of time and have them 'on deck'. If we don't assign new materials we would have to build in the behavior into all the existing materials (which won't all share the same root material )to give us the same result. But, depending on the complexity of the 'operation', this could be acceptable.
|
|
|
|
|
CCP MC Peanut
C C P
C C P Alliance
162
|
Posted - 2014.05.14 13:08:00 -
[11] - Quote
Monkey MAC wrote:
Would it be possible to cheat?
Instead of being absolute black, make it dark enough the human eye can't discern shapes or colours, then invert the brightness like a negative image, then make interactable objects, like infantry, vehicles and equipment emit/fluoresce a darkness/black light, even to a lesser degree instalations could do the same.
Im not sure how well this would work, but it be alot simpler than adding in whole new , material textures.
I realize I didn't respond very well to your question. I will try again.
By cheat, yes--we could do something in the post process chain. Here we can take the entire rendered image and do material effects to it, as if whatever you are seeing is being frozen into a single frame texture. This is cool, but it will pose one issue: the HUD, which we brilliantly moved into 3D, would be part of this frozen texture--we wouldn't want that. There are ways to separate the HUD out, since it is rendered in a different pass (I don't know exactly, but I'm pretty sure it's do-able). So still, this could be a way to go. Typically this is the place to add tinting, contrast, or other image filters. We aren't generally a huge fan of the post process, because it can become costly--and we just prefer doing things in 3D, there are certain situations where it is a good choice. |
|
|
CCP MC Peanut
C C P
C C P Alliance
168
|
Posted - 2014.05.15 00:48:00 -
[12] - Quote
I-Shayz-I wrote:
One of the coolest things about the Dust 514 HUD is TacNet. I absolutely love how much of the gameplay is scanning, hiding from scans, and e-war in general. One of my favorite things is the detailed information given when you look at another player.
However, its placement and complexity makes it very hard to use mid-battle, expecially on HD screens where the information is smaller, and a larger precentage away from a player's reticle.
For example, try looking up at the top of my post and focusing your eyes there while trying to read the text down here. It's impossible. Now try focusing your eyes here and try reading the above line. Much easier isn't is?
But we don't want to see a blob of text over our reticle...that doesn't help anything. Instead, symbols and colors are the best ways for a person to associate meaning. This is on the same page with the shields/armor thing that was mentioned earlier.
There are two things that should be taken from the current tacnet readout at the bottom of the screen and shown as info next to/on top of the health bar:
-Weapon Efficiency (how effective your weapon is against the current shields/armor of the opponent as represented by a green positive percentage or a red negative percentage).
-Meta Level compared to yours (a circle, triangle, or X should be listed to represent whether the opponent has a lower, similar, or higher meta level...this is currently how items are marked in Dust 514)
I'm not yet authorized to reveal the things that are in the works, but I'd say that having built a nice foundation for being able to quickly iterate and implement HUD content, that we would be disappointing ourselves if we didn't take advantage of it. This is one area that can be easily iterated on once a few pieces of data are exposed to Kismet. We do need to find a way to pass dynamic text to Kismet (Kismet is not incredibly good at handling strings)--but even if we can't we can still rely on a renderTarget, and based on your feedback, it sounds like text is less preferred over icons and graphics, so maybe we lucked out on this part.
Bragoltur Valaruina wrote:
Oh, right. I must have missed C. Here you go,
C. Can we get a reticle like the one on the small missile launcher for the small rail gun and blaster?
It is possible to change reticule per weapon, sure. It would be a design decision, though. We are also in the process of moving the 'weapon scopes' used for turrets and snipers out of the post process and into 3D. Otherwise they will be on top of the HUD (not good). |
|
|
CCP MC Peanut
C C P
C C P Alliance
169
|
Posted - 2014.05.15 06:43:00 -
[13] - Quote
CCP Saberwing wrote:Rumour has it he was meant to be McPeanut, but do to his insane turntabling and beat-spitting skills he became MC Peanut.
Let's just say it was serendipitous that I hit the spacebar too much. |
|
|
CCP MC Peanut
C C P
C C P Alliance
173
|
Posted - 2014.05.15 12:37:00 -
[14] - Quote
Ace Starburst wrote:Throwing out a few ideas here that are user interface related.
1. Modules that affect display visualization, such as sonar, x-ray, infrared. Could even have new module slots on the helmet with scouts having the most and heavies/assaults having the least. Possibility of separate types of visual dampeners on low slots. Destructible lights and dark corridors could open up new and interesting strategic possibilities. I can see this one taking quite a bit of work to get right though.
2. Equipment that temporarily disables HUD. (Flux grenades maybe?)
3. Ability to switch to squad mate's vision. Would help in designating targets.
I noticed the sonar part of your feedback and I thought about it a bit. Has anyone seen a sonar/doppler visual mode in any other games? I think we could achieve a sonar visual effect by comparing the vertex normal to the camera normal (dot product) and then factoring in the reflectivity of the surface (which is the specular power--although not all surfaces would have this). The result is that smooth surfaces in the direction you are facing would have a different visual effect (while the rest likely transparent). Although who is to say that your sonar wave projects in a single line--but we could consider a falloff range perhaps. It would be more interesting to account for the doppler effect, which would be worth prototyping. If you colored each pixel based on depth (distance from camera) and had access to a previous frame there could be a way to derive a visualization of things moving (at least moving relative to your position). I can at least bug CCP Photon about this and see what he thinks (of the technical possibility). |
|
|
CCP MC Peanut
C C P
C C P Alliance
180
|
Posted - 2014.05.16 01:27:00 -
[15] - Quote
Thanks for the reference. I wasn't aware of other 'sonar' attempts. I poked around for real sonar maps and found an interesting article: http://www.zmescience.com/other/great-pics/shipwreck-sonar-pictures/
Based on this pic, an effect like this is somewhat achievable. To me, it looks like hue is changing over distance, and the saturation is changing based on reflection angle of the surface. This is do-able, and maybe more scientifically 'accurate', but, of course, if it serves no use for gameplay it is pointless. I imagine that if Titan Fall chose to make the entire screen turn into X-ray mode instead of just overlaying an X-ray effect where players are, it would be too distracting and not useful. Of course, that doesn't mean that the 'in game fictional technology' in these other reference videos isn't seeing the same raw image and not processing it down to a visual effect suitable for the fictional player.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
203
|
Posted - 2014.05.18 13:44:00 -
[16] - Quote
shade emry3 wrote:
You sir have been quoted in the wikia im maintaining, can we get a general background of yourself so we can hyperlink you on our wiki? e,g. technical background, whats your likes and dislikes, if you like long walks on the beach, why your so drawn to art.. stuff like that :) or is their a post relating to this and i missed it?
Wow. You make me feel way cooler than I should. There should be an official dev spotlight happening soon that should cover the information you want, but I'm happy to answer specific questions if you think they won't be covered in the dev spotlight. |
|
|
CCP MC Peanut
C C P
C C P Alliance
207
|
Posted - 2014.05.18 15:10:00 -
[17] - Quote
Aeon Amadi wrote:CCP MC Peanut wrote:shade emry3 wrote:
You sir have been quoted in the wikia im maintaining, can we get a general background of yourself so we can hyperlink you on our wiki? e,g. technical background, whats your likes and dislikes, if you like long walks on the beach, why your so drawn to art.. stuff like that :) or is their a post relating to this and i missed it?
Wow. You make me feel way cooler than I should. There should be an official dev spotlight happening soon that should cover the information you want, but I'm happy to answer specific questions if you think they won't be covered in the dev spotlight. What's your favorite game outside of CCP's titles?
I can't pick a single favorite, but I can break down an 'at the moment' favorite for a few genres (FPS left out to avoid interest conflicts):
Adventure: Secret of Monkey Island
Fighting: Super Smash Brothers
Action: Uncharted Series
Racing: Big Bumpin' (the Burger King Game)
Indie: Hotline Miami |
|
|
CCP MC Peanut
C C P
C C P Alliance
210
|
Posted - 2014.05.18 15:48:00 -
[18] - Quote
Godin Thekiller wrote:CCP MC Peanut wrote:Aeon Amadi wrote:CCP MC Peanut wrote:shade emry3 wrote:
You sir have been quoted in the wikia im maintaining, can we get a general background of yourself so we can hyperlink you on our wiki? e,g. technical background, whats your likes and dislikes, if you like long walks on the beach, why your so drawn to art.. stuff like that :) or is their a post relating to this and i missed it?
Wow. You make me feel way cooler than I should. There should be an official dev spotlight happening soon that should cover the information you want, but I'm happy to answer specific questions if you think they won't be covered in the dev spotlight. What's your favorite game outside of CCP's titles? I can't pick a single favorite, but I can break down an 'at the moment' favorite for a few genres (FPS left out to avoid interest conflicts): Adventure: Secret of Monkey Island Fighting: Super Smash Brothers Action: Uncharted Series Racing: Big Bumpin' (the Burger King Game) Indie: Hotline Miami favorite flight game
Although it's relatively new, I find Kerbal Space Program very satisfying. |
|
|
CCP MC Peanut
C C P
C C P Alliance
233
|
Posted - 2014.05.19 02:02:00 -
[19] - Quote
KAGEHOSHI Horned Wolf wrote: I would very much like racial HUDs to be implemented in Legion, by which I mean the color and visual style of the HUD should reflect the aesthetic of the dropsuit's racial manufacturer; the elements of a Minmatar HUD would look orange for example, and look similar to Minmatar tribal tattoos (example 2). Elements of an Amarr HUD would be gold and be ornately designed similar to the variety of symbols already used in the Amarr Empire.
This is possible to do. My thinking now is that we just create new models for each component (weapon, suit, target, minimap) for all the varieties we need, and then have a way to pick from based upon current stats/equipment. We should consider other areas of the HUD that are/may be dynamic, because it could create a permutation explosion. If we run into a permutation problem, then we would have to move some of this to be dynamically driven, such as a parameter on a material or actor that is driven by a game data value.
KAGEHOSHI Horned Wolf wrote:[Map/minimap] East, West, and South on the minimap. Very important.
Grids on the map/minimap to make calling out locations more effective, similar to how the maps have grids in the map feedback section (example). Your current coordinates should be very easy to tell on the minimap. If possible, the target readout when aiming should also list the coordinates as well.
Building outlines shown on the minimap. This is very important information to know.
I discussed the minimap in detail in an earlier post--it is not something we have fully figured out for recreating in 3D. But your questions regarding the building outlines and grid lines are a bit different. Building outlines need to come from the 3D scene. Currently the minimap is only aware of the "playable area" (which is available as a 2D mask texture). For building outlines we could have 'minimap' geometry that is included with the building (but never rendered in the scene)--doable, but a few unknowns on my part regarding the minimap generation. Content-wise, it would be a bit of work to setup the minimap outline models (although there may a smart shader that could approximate this--depends on the visual effect we want).
GridLines could be included in the base minimap background texture. If we moved that to 3D, we would probably use a 3D icon to label the grid sections and then use a small tiling texture for the grid lines. This may be why it wasn't done before (because a single gridline texture could be huge).
KAGEHOSHI Horned Wolf wrote:
[Team/squad]
Who's talking indicator: A speaker icon along with the name of the person talking should pop up when someone on your team or squad is talking. Also the icon should float over their characters heads so you can visually see who is talking.
Squad list: A list of your squadmates right on the HUD. Should include sqad status indicators:
-Their current suit under their names (to quickly visually identify them)
-Squad leader indicator (duh)
-Shield and armor bar to easily tell who needs help, etc.
-Mortally wounded indicators (name highlighted in red)
-Inside a vehicle indicators (little car symbol)
-Clone terminated/respawning indicators (name is grey, or crossbones symbol)
Total squad WP below the list so you can tell how close to getting a strike your squad is.
An indicator for strikes that stays on the screen until the is used. Sometimes the notifications aren't noticed in the heat of battle, so having them last until the strike is used (or are no longer available).
The squad info can be done by creating squad 'slots' (identified by an ID numnber perhaps) and having kismet events for state change and event handling. This would need to be done with careful consideration on performance, though, because squad information is coming through the server, rather than the client. If we have too much data to update there could be a performance drop. If that is a problem, then it is possible we update at predefined intervals, with single event--this would save performance, but it may result in a less than instantaneous update (although this data does need to be transmitted to your suit anyway)
KAGEHOSHI Horned Wolf wrote:
[Equipment]
Support equipment icons: Its useful to know who is carrying a nanohive, repair tool, and nanite injector, even when you don't currently need those things. It can be very important to know what your teammates can and can't do for you.
Low ammo icon: those who carry nanohives should see a special icon over those with low ammo to indicate the need for nanohives.
Have the equipment that you or your squadmates deployed appear as a green to know which ones are yours or your squad's.
Some sort of notification of when your equipment has been destroyed.
Again, possible, but same consideration as above, regarding data coming through the server. Also much of this information would need to be on a 3D Icon in the scene, rather than planted on the HUD.
KAGEHOSHI Horned Wolf wrote:
[Weapon]
A different crosshair to indicate when a weapon is done charging, right now its hard to tell when for example a forge gun is fully charged because the charge gauge is all the way down inside the ammo meter; I shouldn't have to take my eyes of the target to check if fully charged. This would not be needed if all weapons had a distinctive sound, animation, and/or visual effect synchronized with charge completetion to queue the user. This... |
|
|
CCP MC Peanut
C C P
C C P Alliance
237
|
Posted - 2014.05.19 03:06:00 -
[20] - Quote
Maken Tosch wrote:KAGEHOSHI Horned Wolf wrote:Thank you for the reply, what HUD features are among your goals for Legion by release? What do you foresee the HUD being like? This I like to know as well.
This is not something I am able to comment directly on, unfortunately. I am not in a position to make decisions on what we ultimately implement. What I can say is that the new HUD pipeline is dramatically more flexible such that our artists and designers can be more directly involved to implement the things that they want. I can say that the feedback is immensely helpful and you guys have challenged me with lots of questions that have made me re-examine some of our system implementations (which is good). |
|
|
|
|
CCP MC Peanut
C C P
C C P Alliance
258
|
Posted - 2014.05.20 00:45:00 -
[21] - Quote
Sole Fenychs wrote:So, what about making things pretty?
I played all of the Metroid Prime games, which do some really awesome HUD effects to add to the immersion.
Like, if a map has valves that blow steam into a room and you walk into that steam, your vision gets obscured. Icy regions cause your screen to show ice crystals on the borders. Damage would produce static and EM weapons would cause the HUD to fade in and out. Or, when an explosion goes off in front of your face, you can see the reflection of your face on the inside of your visor.
The latter would obviously not make sense for this game, considering that we aren't looking through transparent visors. Well, at least for the Medium suits that seems to be the case - The Caldari and Gallente scout look like they might actually have visor systems.
This is something we can do by adding material effects on the visor mesh. These are pretty fun to create actually. You have a lot of things to utilize also. We could distort the scene behind, overlay ambient effects (such as ice, steam, or water droplets). Also we can capture the scene (behind) as a texture node (within the visor material) and do all sorts of things to it (invert, contrast, distort by texture coordinate (different than the built in distortion and I think it looks better).
We aren't really working on this kind of stuff now because, while it can affect gameplay and should be balanced and considered by designers, it is still a post-style effect, that should be figured out after all the root systems are in place. |
|
|
CCP MC Peanut
C C P
C C P Alliance
258
|
Posted - 2014.05.20 00:46:00 -
[22] - Quote
ANON Cerberus wrote:CCP MC Peanut wrote:Maken Tosch wrote:KAGEHOSHI Horned Wolf wrote:Thank you for the reply, what HUD features are among your goals for Legion by release? What do you foresee the HUD being like? This I like to know as well. This is not something I am able to comment directly on, unfortunately. I am not in a position to make decisions on what we ultimately implement. What I can say is that the new HUD pipeline is dramatically more flexible such that our artists and designers can be more directly involved to implement the things that they want. I can say that the feedback is immensely helpful and you guys have challenged me with lots of questions that have made me re-examine some of our system implementations (which is good). While it sucks that you cant give us a brief artistic description of what you envisage, I understand that isn't your prerogative. That being said, you have been invaluable on the forums recently, especially in relation to the UI as a whole. You have posted more in this single thread over the last week or so, than we have probably gotten in dev blogs since forever. So a BIG thankyou for spending the time to talk about things. Not all of us fully understand everything, however its great that you are putting in the time and effort with the community. +1 good sir!
You're welcome. Thank you for the kind words. It will only encourage me to post more. |
|
|
CCP MC Peanut
C C P
C C P Alliance
274
|
Posted - 2014.05.20 15:18:00 -
[23] - Quote
Bragoltur Valaruina wrote:Fox Gaden wrote:This is one of my classic rants, but I donGÇÖt think I have posted it in here yet.
Each squad member should have a number on their dot on the mini map which corresponds to their position in the Squad list. This number should also display above their heads when you look at them.
This will facilitate the communication, as you will be able to quickly identify someone by their number and relay information to them. The classic example is GÇ£Hey Dot 4, you got a shotgun on your 6!GÇ¥
When working closely with a squad I often see things I need to warn other squad members about, but I have no way of identifying which squad member I am addressing. A lot of times in DUST, I would not know how to pronounce someone's name, even if I could see it well enough to read it. A number would work fine as long as the HUD makes it clear to each person what number they are. A number would also be easier to display and easier to read than a name.
Edit: For team deploy we could have two numbers. The first represents which squad you are in, and the second represents your position on the squad list. Alternatively, since there will not be a lot of squads, we could use just the squad list number and color code it according to which squad you are in. So you might be Green 3, or Black 5, or Orange 6, depending on which squad you are in (color) and your position in the squad (number). I totally agree. Is there any way that this could be implemented, MC Peanut?
I'm sorry I must have missed Fox's post as it feels like I am reading this for the first time. Please feel free to bump a question if I don't give a direct answer.
I'd wager this is possible and much more plausible if we setup a robust 3D Icon system. Dynamic text rendering should be a part of this icon system, so we can have a Mesh Icon (a generic squad icon) with a small plane mesh in front, or on the corner (containing a numeric value). I am guessing a little here as I am not familiar at all with the current squad setup. Color would also be a way to handle further information depth, but the server would likely need to assign the colors to the squads and then send it through kismet--probably not a performance issue since it happen infrequently. Also, if we want to display an icon over the player, we should be able to utilize the same icon, or an icon derived from the same base, as from the HUD.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
285
|
Posted - 2014.05.21 00:58:00 -
[24] - Quote
501st Headstrong wrote:That sounds swell. How possible would it be to add curvature to the Hud, so it actually looks like an helmet? Even though this isn't reality, in life you can glance to your left or right and see area to your ears without turning around entirely. The screen could curve so you can slightly see to your right and left, and a little bit perpendicular your nose. This would challenge flanking players to really work hard for the kill, because running from the side of a person should not be as easy as it is, and really add immersion. Saw a grenade blast near your ear? Holy crap I should see what that came from. Getting shot from your left, you may see bullet trails from that direction, giving a much better indication of where the shooter is.
Yes, I know there should be situational awareness, but only having a 45 degree view of what is in front of us when we have a near 90 or 180 actually is quite interesting. To aid in balance, make the edges and side blurrier, so if you glance you can see your side, but to get a crisp image you need to turn as we do now. In life, what is in front of you is the focus, so you aren't constantly distracted by things your outside. And yes, I know we should invest in precision enhancers, but other than that-
Thoughts?
This could be hard to present well because there is not a distinction between head, torso, and feet movement when turning. Some games handle this by having the head rotate first, up to a tolerance, then an animation kicks in and the player takes a few steps turning the body to 're-center' the head. This works better in a 3rd person mode because it is subtle and it doesn't really affect gameplay. In the first person view it may be hard to tell when you've reached your head turn tolerance. But it may be ok if it is a subtle effect and doesn't move the HUD much. Still, this would require that we track the tolerance and 're-center' when it is exceeded, which is something I don't know. If further discussion happen on the movement, I'll try and bring this up. |
|
|
CCP MC Peanut
C C P
C C P Alliance
285
|
Posted - 2014.05.21 02:04:00 -
[25] - Quote
Oops. Not answering full questions strikes again. Yes it is possible to actually change the camera Angle of View so you can see more, but it could have affects on other areas that are affected by camera depth and angle--it could also just be too much information on screen and would either be visually displeasing or reduce performance (more to render) . If we widened the angle of view, then it would be possible to take the Visor HUD mush (which is curved) and apply some sort of distortion on the edges. It would be a similar technique to what is used in the turrets, but I'm not exactly sure realistic it would look. The distortion effect basically shifts the underlying pixels in an x or y direction based on a 0-1 color value--there is a bit of compression/expansion in play, but it is not something I've found easy to control (although it is something we can investigate further).
But again, this is a major change of the presentation that game designers and higher ups would make. I can make them aware of its possibility. |
|
|
CCP MC Peanut
C C P
C C P Alliance
295
|
Posted - 2014.05.21 14:20:00 -
[26] - Quote
We do have a separate FOV control on the HUD geometry. So changing the game FOV would not affect this. Thank you smart engineer who thought to do this in advance. |
|
|
CCP MC Peanut
C C P
C C P Alliance
334
|
Posted - 2014.05.22 08:33:00 -
[27] - Quote
CCP MC Peanut has a youtube channel now
I got permission to upload some footage of the compass. The texture is still a work in progress and will be updated later by artists, but you can see it moving with the camera.
https://www.youtube.com/watch?v=rTk3C5HPoZs
|
|
|
CCP MC Peanut
C C P
C C P Alliance
338
|
Posted - 2014.05.22 12:37:00 -
[28] - Quote
CEOPyrex CloneA wrote:Assume this compass can be interfered with via EW modules? perhaps it also doesnt work on certain planets due to interference / no magnetic fields (if powered that way)
How about making this a module that has to be setup as the match starts to enable certain HUD devices / widgets and can be attacked by cloakers who can disable certain HUD functions either by EW grenades or killing a planted device acting as an intel uplink?
(how about eve players deploying satellites in orbit for certain intel features?
omg my brain hurts but gg chaps, keep the vids coming.
Wow that is a fantastic point that I hadn't yet thought of. It would be very easy to 'mess' with the compass. We could offset it by a wrong value, or even merge in a 2nd value that is animating. I'll point some designers to your post. |
|
|
CCP MC Peanut
C C P
C C P Alliance
356
|
Posted - 2014.05.23 00:34:00 -
[29] - Quote
Maken Tosch wrote:Foehammerr wrote:MC Peanut, when I watched the clip of the compass, I noticed that (to me at least) the rotation of the compass feels unnatural and counter intuitive. Having the compass act static and behave as if the user is looking inside a circle would be better in my opinion. What i mean by that is to have the compass rotate the opposite way of which the user turns.n++
It could be that he's basing it off the way a magnetic compass looks to an aircraft pilot in real life. Many such compasses on airplanes work like that.
Good catch. Actually I already flipped it to rotate reverse (CCP BaoZi pointed it out), but that wasn't in the build I recorded from. So it obviously gives me room to post more videos. |
|
|
CCP MC Peanut
C C P
C C P Alliance
365
|
Posted - 2014.05.23 09:00:00 -
[30] - Quote
Since someone noticed the backwards rotation, gotta update, or risk losing coolness points: http://youtu.be/mumOikxPNjs
|
|
|
|
|
CCP MC Peanut
C C P
C C P Alliance
368
|
Posted - 2014.05.23 12:18:00 -
[31] - Quote
Aeon Amadi wrote:My only recommendation is a marker for true north. Looks great, not going to lie, but to someone who doesn't have knowledge of how aircraft compasses work it looks like a bunch of numbers that are relative to my position. Also, what's the scale of the compass? 0-100? 0-360? This kind of information could greatly help tactical communication. If 0 is True North, then I can tell my team-mates that the sniper is "Twenty degrees from my location" or something to that extent.
Yes absolutely. I agree--I didn't even know it was moving backwards with the numbers. It would have been more obvious if I turned right and suddenly I'm facing West. I'm pretty sure the artists, when they update the texture for this, will add some markers, but I can't say for sure.
As for displaying objectives and such on the compass (an earlier question asked this). This is a little more complicated than the compass itself, as the position is related to the objective position and your position/orientation. Actually, when I first thought about it, I thought this was hard, but then after a day I realized it isn't. You just need a normalized vector to the objective and the players facing vector--then you can figure out the angle (same way with the compass--arctan2). This could actually be done with a shader, but you would need texture sampler for each objective. Also you could create a different polygon ring for each objective and let them sit slightly on top (so close you couldn't tell). The hardest part is getting the position of the objective--this wouldn't be immediately available in the shader, but it could be set with an event, as objectives don't change position (but if we wanted to track other things that do change position that may need to use a different way).
Wow--this is cool--totally do-able. Thanks for making me think about it. I'll propose it to the team.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
406
|
Posted - 2014.05.24 03:22:00 -
[32] - Quote
Aeon Amadi wrote:^_- Combine this sort of tactical viability through information gathering with a grid-map on the actual overhead and you've given the guys on the ground everything they need to effectively communicate in the same way that we would in the military. Can play into a whole new meta for effective squad leaders/commanders who can accurately read into the battlefield and provide that information effectively to their team. Congratulations, you just achieved everything Field Command leaders have been asking for. EDIT: Oh, right - on that note - if we do get a grid-layout for the map... Any chance you could include what grid we're in on our HUD? Just something simple, off in the corner or next to the compass to signify that I'm in G6 or where-ever. That way someone can tell me that "Enemy is at H7" and I know exactly where I need to be / how close they are, instantly  Here's an example of what I'm trying to illustrate: http://i.imgur.com/ScbP8SX.pnghttp://i.imgur.com/k4m9amb.jpgANOTHER EDIT: Albeit in retrospect that may be rather difficult to accomplish. Your call though.
I know they previously looked into a grid overlay on the overview map before, but they ran into issues with the terrain being in 3D and the UI being done in 2D Postprocess--this doesn't work well because the terrain has depth and the grid overlay is flat and above the terrain--it will not line up properly.
It can be achieved if the grid is done in 3D. There is one shader technique where you can draw pixels only at the intersection points of polygons. I attempted a small prototype by adding some polygons that intersected with the terrain (they are huge), but the thickness of the 'line' changes too much with slope and distance, so we would still need to figure out a way to improve this (and there are ways). Another way this could be done is by building it into the material on the terrain and use WorldSpace mapping coordinates (basically you can use the x,y value as a texture coordinate). This seems better and I'm leaning more towards it (although the first technique would be useful if we wanted to show a scan effect going across the landscape). Still there is a roadblock in figuring out how to apply this grid material--we don't want to it as part of the terrain material all the time--some of the starmap work is requiring something similar, so I'm hopeful we can learn from that.
If we can make certain our overlay map is placed mathematically correct, then it shouldn't be too hard to display what quadrant you are in. In fact, this could be completely done on the content side if the terrains always align to the same world space point (which I believe is true). In the material for the grid coordinate we just look up the world space coordinate and convert it to a grid coordinate--then we have a texture with each coordinate label in a grid (like a texture atlas), and we shift our mapping coordinates appropriately. Probably not too bad, but I'm simplifying the steps and might be missing something (ducks).
The-Errorist wrote:
In the description of the domination game mode for Legion, it said that the object changes every 10min, so that might be a problem.
Actually it is ok if it switches in frequently. I was more referring to marking positions of things that could be frequently (like every frame) moving, such as a player. |
|
|
CCP MC Peanut
C C P
C C P Alliance
409
|
Posted - 2014.05.24 13:09:00 -
[33] - Quote
Aeon Amadi wrote:CCP MC Peanut wrote:The-Errorist wrote:
In the description of the domination game mode for Legion, it said that the object changes every 10min, so that might be a problem.
Actually it is ok if it switches infrequently. I was more referring to marking positions of things that could be frequently (like every frame) moving, such as a player. Don't we already do this with Squad Orders though? Not bringing that up as a way of saying "Hey, copy/paste the methodologies of that here" I'm saying that as: If we already have the functionality to track a moving player with squad orders, no reason to add something that does the same thing =P
Yea we already do that and are doing it in a 2D system and generally it works fine. If we moved this to a 3D system we would be able to better control (on the content side) the visual rendering of these icons. We would also be able to add more complex /dynamic information, such as animations, dynamic text, visual states, and shaders (like a health bar on an icon). It may also give us more flexibility to expand on it since it becomes more content driven. However, we would likely only move to a 3D system if we felt the benefits were worth the cost of moving. In the case of the HUD, the benefits were worth the cost.
As for doing this on the compass--this can't use the existing system because the compass exists in the 3D world while the current icons are drawn in 2D (using 3D positions and converting to screen position). Also we probably can't track the player position on the compass using the method I described above because it would require constant updating, and kismet is not great for that--this would be better to be done on a custom actor class and controlled within the class itself (faster).
Or am I missing your question again. I am actually not incredibly familiar with the workings of squad interaction so I may be missing the point.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
411
|
Posted - 2014.05.25 01:28:00 -
[34] - Quote
Ulysses Knapse wrote:A few questions. Pardon me if these have already been answered, I only just noticed this thread.
1. A semi-common feature in shooters is to have your ammo amount be displayed holographically next to the weapon. Would it be possible to implement this as an toggleable feature, perhaps also showing heat as well as ammo?
2. If we ever get speedometers, how would you feel about implementing an accelerometer as well for vehicles, especially aircraft? It would be interesting and helpful to know how fast I'm speeding up as well as how fast I'm currently going.
This is another benefit to moving 3D that I didn't really talk about, but yes, as the HUD is in 3D now, the content is setup in a very similar way as a weapon (in fact on my first visual prototype I replaced a weapon to get it into game). This means we can attach a polygon to a weapon (or a weapon joint) and have some UI element look projected from the weapon. It also means we could take our existing HUD materials (such as an ammo bar) and map them directly on weapons (although this could be a bit annoying because someone would have to go back on all the weapons and add some new polygons).
For speedometers, we should have the velocity value, but this is something that may be difficult to display like the other HUD because velocity is constantly changing--I would be concerned the update event would experience lag or be a little choppy--an Engineer may have a better answer (I only have a concern). If we didn't do it this way we may be able to use animation trees, which should be more responsive to handling parameters that change constantly. I've felt we would eventually need to include animation trees into the HUD/3D UI system anyway. |
|
|
CCP MC Peanut
C C P
C C P Alliance
414
|
Posted - 2014.05.25 10:33:00 -
[35] - Quote
I-Shayz-I wrote:Iron Wolf Saber wrote:Any chances for interhud glass effects?
Like walking through a steam vent fogs up the hud glass? (ala Metroid Prime effects?) I was interested int this idea at first...but the dropsuits we have in Dust aren't like space suits with helmets. In other words, our merc isn't looking through a face shield/glass Instead it's more like Ironman where there is a holo display inside the helmet, and that displays whatever the outside cameras are displaying. MCP replied about this a few pages back...another thing was balancing and making sure that certain effects won't have any ill effect on gameplay to make it unfair or not fun. Still, the cameras have to have some sort of shield cover or protection against the elements, so there's always the possibility. My favorite effect from the Metroid Prime games had to have been the way you'd see a flash of Samus' eyes reflecting in the visor when there was a bright light or when missiles hit near you. Either that or when you'd get hit with some sort of EMP blast that made you have to restart your suit system before you could get your HUD back. Talk about putting you in the game...immersion at its finest in those games for sure.
Thanks for the assist. Nailed it.
|
|
|
CCP MC Peanut
C C P
C C P Alliance
415
|
Posted - 2014.05.26 11:20:00 -
[36] - Quote
Iron Wolf Saber wrote:Of course; also issue of performance as well.
Metriod prime's effects I felt while nice where a bit too powerful for a multiplayer competitive environment.
However there been other games that have made the effects terrible
Namely the bleeding blood splatter and 'health bar'
Including dust 514's own repair aura.
Immersion details is just the sprinkles on top of the ice cream not the fudge ribbon.
Since we are on the topic of screen effects... I've posted a very early prototype of doing one. This is so early, you will see the 3D HUD is still mostly un-textured polygons (it was probably going through a makeover at that point). So please excuse the ugliness there, but I thought it would be cool to show off at least a little proof that this type of thing is possible. The fog effect is a translucent material (with a color of white). There is also a little bit of blurring going on, but the blur control has since been improved, so I know we could achieve an even more realistic effect here. Of course, as discussed, an effect like this is questionable if it really follows the fiction of the suits having screens and cameras. Still, the technique remains the same: visor mesh + shader with access to the screen texture.
http://youtu.be/-TUr4W9vOG4 |
|
|
CCP MC Peanut
C C P
C C P Alliance
421
|
Posted - 2014.05.27 01:06:00 -
[37] - Quote
Fox Gaden wrote:
You realize that if you do that, then you would have the option of projecting the grid onto the HUD so that solders would see the grids as an overlay on the live environment, just as the other blue and red items are overlays. (Might want to make this an optional feature that can be turned on or off.)
since reading your post, I now realize that, and agree--this is a very smart way of handling it. I also know that the terrain shader is already quite complex and may not have room to support another texture sampler (there some limits to how many texture samplers you can have in a shader). But it is definitely worth mentioning. I was thinking in the overview map we could use a lighter weight version of the terrain shader if we needed to. They have a lot of really cool fine details that would never be visible from the overview.
Bragoltur Valaruina wrote:Could you give the player an option (maybe on the tactical map) to view the map in orthographic or perspective mode? In orthographic you could overlay a 3D grid over the map with no warping. I personally think the radar/hopefully soon to be mini map, should always be orthographic. For those who might not know, "Orthographic projection (or orthogonal projection) is a means of representing a three-dimensional object in two dimensions." Via http://en.m.wikipedia.org/wiki/Orthographic_projection
You are right--this is another way to do it. I don't know if we can set the camera in game to be orthographic, but you can definitely set the editor cameras to be orthographic, so the functionality does exist. There may be a visual issue with an orthographic look, though. But if we can set it up in game I'd say it is worth a try. I'll bring this up when/if we tackle the overview map.
Aker Ghaal wrote:Ello Peanut!
I just wanted to chime in and say great work as of yet! It is pretty much the way I wanted to see you guys to proceed in terms of UI/HUD elements. Also cheers for the YouTube channel and the continued discussion and feedback you give us here in the community! With that said, regarding a few points you have made considering racial HUDs/transitions and a few immersive UI elements. Could you guys over at the CCP give your points on my thread on UI elements, especially the idea of transitions and the removal of load times in between actions? LINKAlso start up sequences for dropsuits and vehicles would be a cool idea worth exploring. Check out this game for the xbox called Steel battalion and their startups. You might not need the startups to be as flashy as theirs but it would be nice idea for the removal of transitions: LINKWatch all of the ones in the play list to get an idea of the variety of startups that could be possible.
Whether or not you guys check it out I am happy just for the sake of the work your doing, I am interested in seeing more! Keep up the good work!
I actually saw your images before--someone linked them earlier in this thread. Very cool. It is so exciting to see you guys contributing. Also a boot sequence is much easier to do now since we have more control on the content side. We can create matinee sequences and trigger them with kismet events. In fact, the fog effect prototype I did would be a good example of something we could play in the boot-up sequence (the video you see is actually controlled with a matinee sequence).
Joseph Ridgeson wrote:
I have to agree with IWS on this one. Having watched the video with the intense sun glare (thanks for sending those out; it is great to see that kind of stuff) I can say that it could be a pure detriment to the game if it is that intense. I think back not to games, like IWS did, but to movies. Effects like a slightly shaky image or blood/liquid hitting the camera can add great immersion to a scene in it being chaotic or frantic; it gives you the impression that you are there. However, when any effect is overdone it pushes it away from "Holy s*** this is frantic and intense" to "why the hell did they decide to do that?"
Agreed--we do have to be careful about that. These effects are very much a game design call. Regarding extreme glares--we have some awareness of the pixels being rendering behind the HUD elements, so we could add some logic in there (in the shader), to say, make it darker when the background is super bright. I've only done a few experiments--it looks like it could work--there are a few ways to go about it actually, but it is a per pixel thing, so it can be a bit tricky to get an 'even' darkening
|
|
|
CCP MC Peanut
C C P
C C P Alliance
449
|
Posted - 2014.06.05 00:06:00 -
[38] - Quote
Maken Tosch wrote:Any updates so far, Peanut?
Recently I have been more involved with the Starmap work so not a lot is happening related to the HUD. I've had a few conversations with the guys working on the Salvage stuff just so they are aware of the kinds of things we can do--I believe we will be able to do some cool things with the HUD here, but it is important they are aware of the way it works so they can expose the information in the right way for the HUD.
Outside of this I've been supporting CCP Photon as he works on integrating text rendering--this is a big next stuff for the 3D HUD--or 3D UI system. After this our goal is to implement a few 'simple' widgets in 3D, such as a label and text field. Currently we are using a lot of the work done on the Starmap as a guideline for how to 'organize' this. Although the difference is that the Starmap spawns every asset through code, where 3D UI elements will need to be able to be place by the artist. Although there could be a middle ground here, where the artist places sockets in a 'layout' and the UI system still spawns the appropriate actors at said sockets. This is very early thinking right now--still needs a few more conversations and maybe some experiments until we have a clearer picture. |
|
|
CCP MC Peanut
C C P
C C P Alliance
451
|
Posted - 2014.06.05 03:11:00 -
[39] - Quote
Maken Tosch wrote:CCP MC Peanut wrote:Maken Tosch wrote:Any updates so far, Peanut? Recently I have been more involved with the Starmap work so not a lot is happening related to the HUD. I've had a few conversations with the guys working on the Salvage stuff just so they are aware of the kinds of things we can do--I believe we will be able to do some cool things with the HUD here, but it is important they are aware of the way it works so they can expose the information in the right way for the HUD. Outside of this I've been supporting CCP Photon as he works on integrating text rendering--this is a big next stuff for the 3D HUD--or 3D UI system. After this our goal is to implement a few 'simple' widgets in 3D, such as a label and text field. Currently we are using a lot of the work done on the Starmap as a guideline for how to 'organize' this. Although the difference is that the Starmap spawns every asset through code, where 3D UI elements will need to be able to be place by the artist. Although there could be a middle ground here, where the artist places sockets in a 'layout' and the UI system still spawns the appropriate actors at said sockets. This is very early thinking right now--still needs a few more conversations and maybe some experiments until we have a clearer picture. I see. have you considered the Sensor Overlay created by Team Five O or least making a Legion version of it as part of the 3D HUD in conjunction with Salvaging? I see this as something very helpful so maybe if you can get in touch with Team Five O to see if it's possible to bring this feature over that would be great.
This is pretty cool and is definitely something we would want to look at incorporating if it fits with the design for the Salvage scanning mechanic. I know that this could be implemented as a 2D overlay, but it could also be done with rendering trickery. We could just create invisible meshes that are attached to other actors that should register on the scanner and then, on scan, make them visible(and render on top of everything). Then we don't really have any math to do. Also we could control the transparency based on distance if we wanted to account for a range of your scanner (and that range could vary). |
|
|
|
| |
|